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Wc report on an experience to support multiple views of programs to solve the tyranny of the dominant 
decomposition in a functional setting. Wc consider two possible architectures in Haskell for the classical 
example of the expression problem. We show how the Haskell Refactorer can be used to transform one view 
p^ \ into the other, and the other way back. That transformation is automated and we discuss how the Haskell 

^ ■ Refactorer has been adapted to be able to support this automated transformation. Finally, we compare 

*rt ', our implementation of views with some of the literature. 
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Evolutivity is a major criteria of quality for enterprise software. Evolutivity is strongly related to the design 

M-l choices on the software architectures. However, it is generally impossible to find software architectures that 

**\ ' are evolutive with respect to all concerns. So, one of these concerns has to be privileged (section |2T|) . 

C*2 , As shown by the solutions to the expression problem [28] . there are many ways, often based on specific 

language features, to provide modular extensions which are orthogonal to the main axis of decomposition 

of the architecture (section 12.21) . However, these solutions focus on extensions and generally break the 

regularity of the initial architecture, leading to a decrease in the maintainability (section |2.3[) . This shows 

that the modular extensibility and maintainability on orthogonal concerns are difficultly supported at the 

language level. 

^vq , Multiple views [7] tackle the problem of modular evolutivity with a program transformation approach 

instead of a programming language approach. For a given application, the source code of several equivalent 

iy~\ , architectures can be computed one from another, so that the programmer who has to implement an evolution 

can choose the architecture which his the most convenient for his task. With proper tools, the implemented 

^D . evolutions are reflected in all the available architectures. 

In this paper, we report on an experience of providing support for multiple views for a functional lan- 
guage. In the following, we consider the classical example of a simple e valuator coming from the expression 
problem |28j and we illustrate how multiple views can provide modular extensions as well as modular 
changes on several orthogonal axis (section [3]). Then, we propose an implementation of a transformation 
from one view to another. That transformation is based on a refactoring tool (section [4]) . Last, we discuss 
the work to make this kind of tool usable for enterprise software (section [SJ and we compare our experience 
to other tools for multiple views (section f6.3|) . 



2 Modularity and Evolution 

In this section, we illustrate the tyranny of the dominant decomposition in a functional language setting 
with a simple example (section [2. ip . we recall the definition of the expression problem (section l2.2[) , which 
is closely related to our problem, and we focus on maintenance and show that it is not well covered by the 
expression problem as extensions tend to degrade the initial structure (section I23f . 



'This is the second version of the report initially entitled Views, Program Transformations, and the Evolutivity Problem. 



2.1 Each Architecture privileges extensibility on a given axis 

When choosing a module structure for a given program, one has to choose between several possibilities with 
different advantages and disadvantages [22]. We illustrate this with two possible module structures for a 
simple evaluator which have dual advantages and disadvantages. This program is the same that is often 
used to motivate the expression problem, here given in Haskell. 

data Expr = 
Const Int 
I Add (Expr, Expr) 

eval (Const i) = i 

eval (Add (el,e2)) = eval el + eval e2 

toString (Const i) = show i 

toString (Add (el,e2)) = (toString el) ++ "+" ++ (toString e2) 

The data type Expr represents the expression language to be evaluated. This data type has a constructor 
for literals (Const for integers) and another for an operator (e.g., Add represents the addition). Two 
functions, for evaluating or printing expressions, are defined by pattern matching: a case is provided for 
each constructor. 

This code is modular with respect to functionalities (because of the scope introduced by function dec- 



larations). The modularity is better seen in Figs. [T] and 2(a) where modules are used to structure the 
program. 



module Expr where 










data 
1 


Expr = 

Const Int 

Add (Expr, Expr) 










el = 


Add (Add (Const 


1 , Const 


2) 


, Const 


3) 


e2 = 


Add (Add (Const 


, Const 


1) 


, Const 


2) 



module EvalMod where 
import Expr 

eval (Const i) = i 

eval (Add (el,e2)) = eval el + eval e2 



module ToStringMod where 
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module Client where 
import Expr 
import ToStringMod 
import EvalMod 

rl = print (toString el) 

r2 = print (show (eval el)) 

r3 = print (toString e2) 

r4 = print (show (eval e2)) 



Figure 1: Functional decomposition in Haskell - program P] 
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Figure 2: Coverage of modules with respect to functions and data constructors 



Fig. 2(a) shows a matrix indexed on constructors and functions where the modules of interest have been 



pictured. For instance, the module EvalMod deals with the two constructors but with only one function. 

This program architecture makes it easy to modify an existing function since the code to deal with is 
localized by syntactic module boundaries. It is also easy to add a new function by adding a new module. 
However, this code is not modular with respect to data constructors. The code corresponding to a given 
constructor (e.g., Add) crosses module boundaries. So, when the data type is extended and a new constructor 
(e.g., Mult) is introduced, each function module must be modified in order to take into account the new 
constructor. 



Figs. [3] and 2(b) describe an alternate code architecture. That structure gathers all the pieces of code 
related to a given constructor into a single module. For instance, the module ConstMod collects the parts 
of the definition of eval and toString for the Const case. Fig. |2(b)| pictures this architecture: modules in 
the matrix do not cover functions anymore but constructors. 

This alternative code is modular with respect to data constructors. Indeed, this program structure 
makes it easy (modular) to add a new constructor (e.g., Mult for a product): the corresponding module 
is introduced (and fold is extended with a new case). However, this code is not modular with respect to 
functionalities: the code corresponding to a given function (e.g., eval) is spread in all constructor modules. 
So, when a new function is introduced, each module must be modified in order to take the implement the 
new function. 

This illustrates the tyranny of the dominant decomposition in action. Whatever primary program 
structure is chosen, some extensions will not be modular. 



2.2 The Expression Problem 

The problem we have described has been subject to many proposals in the context of the so-called Ex- 
pression Problem (see [29] for a review of some solutions). The expression problem tries to tackle modular 
extensibility from a language point of view and imposes constraints that are coherent for this point of view. 
These constraints are the following [2"5] : 

• The extension should come as a separate file/module and should not require to modify existing 
files/modules. 

• The files/modules that were already in the program before the extension should not be recompiled. 

• The type system should be able to ensure that the extension is safe. 

Several works (for instance those listed in [29]) show that specific features of the host language makes 
it possible to design a program structure where it is modular to extend the data type, and also modular 
to extend the functionalities. However, as we will see, these solutions share a drawback: maintenance is 
not modular. Indeed, successive evolutions tend to break the initial structure [5J. This is not taken into 
account by the expression problem. 



2.3 Extension is only part of the problem 

In order to illustrate the deviation from structural regularity with referenced solutions to the expression 
problem, we consider an incremental development scenario for our example of application. However, we 
abstract the code of our example and consider a data- type with two constructors CI and C2 (instead of 
Const and Add), as well as two functions f 1 and f 2 (instead of eval and toString). 
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module ConstMod ( t oStr ing , eval ) where 
toString x = show x 
eval x = x 



module AddMod 


(toString , eval) 


where 


toString x y 


= x ++ "+" ++ y 




eval x y = x 


+ y 





module Client where 

import Expr 

import ConstMod ( eval , toString) 

import AddMod ( eval , toString) 

toString x = fold AddMod . toString ConstMod . toString x 

eval x = fold AddMod . eval ConstMod . eval x 

rl = print ( Client . toString el) 

r2 = print (show (Client. eval el)) 

r3 = print ( Client . toString e2) 

r4 = print (show (Client. eval e2)) 



Figure 3: Constructor decomposition in Haskell - program P, 



data 



The initial program considered in this scenario has an architecture focusing either on function extensi- 
bility or on data extensibility, depending on a design choice. These two possible architectures are pictured 
in the following two diagrams. 
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The left hand side diagram means that there is a module^ for each constructor of the data type and 
the code of the functions is spread over these modules. This illustrates the situation in the architecture of 
Fig. [3] and also in the classical object approach (Composite design pattern). The right hand side diagram 
means that there is a module for each function and the code corresponding to a constructor of the data 
type is spread over these modules. This illustrates the situation of the classical functional approach (Fig. [1]) 
and also in the Visitor design pattern. 



1. 


Extension : Introduce a new constructor C3 (for instance Mult). 


2. 


Extension : Introduce a new function f 3 (for instance derive). 


3. 


Extension : Introduce a new constructor C4 (for instance Div). 


4. 


Extension : Introduce a new function f 4 (for instance check_div_by_zero). 


5. 


Maintenance : Modify the function f 1. 


6. 


Maintenance : Modify the data constructor CI. 



Figure 4: Evolution scenario 

We now assume that we have chosen a particular solution to extend any axis by providing a new module 
(for instance, one of the solutions cited in |29j ) and we examine what happens with the scenario of Fig 2) 



The progress of this scenario is illustrated by Figure 5(a) and is detailed below. Grey zones in the figure 
represent the code which has been added or modified. 



Two first extensions (evolutions 1 &: 2). After the first two evolutions, we are in one of the following 
situations, depending on the initial program: 
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In the left-hand side diagram, the extension of the data type with C3 is natural, and adding the function 
f 3 can be done with the chosen specific language feature (in this case, the "module" for f 3 has a different 
nature from the three other modules of the application) . 

In the right-hand side diagram, we have extended f 1 and f 2 with the chosen specific modular feature to 
take C3 into account and then we add f 3. If we want the extension for f 3 to be fully modular, we have to 
define f 3 on CI, C2 and C3 in a single module. (Another solution would have been to make a module with 
f 3 defined on CI and C2 and to complete the module of C3, but we do not consider this is modular). Even 
if the modules for f 1, f 2 and f 3 arc of the same nature, they do not cover the same subset of constructors. 

This means that one cannot fully rely on fl or f 2 as patterns to write f 3 (problem 1: loss of regularity 
for extensions). 



'We generalize the definition of module to: "any modular entity of the programming language". For instance, a function 
definition is a modular entity. 
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5: maintenance 
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(a) Progress with a language- level solu- 
tion for two initial architectures. 
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(b) Progress with architecture transformations. 



Figure 5: Progress of the evolution scenario in different cases. 



Two following extensions (evolutions 3 & 4). Now, let us take two more extensions into account. 
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In the left-hand side diagram, C4 is added naturally as a module, but we see that the corresponding 
module does not cover the same functions as the modules for CI, C2 and C4 (this boils downs to the 
problem 1). Then f4 is added with the same technique as f 3 but, again, the module for f4 does not cover 
the same cases as the module for f 3. 

We meet the same problems in the case of the right-hand side diagram. 

We can observe that the regular architecture of the initial programs rapidly becomes disordered with 
incremental extensions. This will reveal to be bad at maintenance time. 

Maintenance time (evolutions 5 & 6). Now we have to modify f 1 (to correct an error or to cope 
with a change in its specification). In the (initially) data-centered architecture (left-hand side), the code 
for f 1 is already spread over several modules in the original program. In the (initially) operation-centered 
architecture, the code is finally also spread over several modules. This means that we have lost the benefit 
of the initial modularity: the maintenance is no more modular (problem 2: loss of the initial modularity 
properties). 

This is the same for the maintenance of CI: in the data-centered architecture, the code has become 
spread over several modules. Moreover, the number of modules on which the code dealing with a constructor 
is spread is different for CI and C3. 

The example of this section shows that the technical solutions for modular extensibility are not sufficient 
for modular maintainability. 

3 Views and Transformations 

Multiple views [7] aim at solving the problem described in the previous section. We now recast this in our 
setting. 

3.1 Programs and Views 

We call views of a program two or more textual representations of programs that have the same behavior 
(they are semantically equivalent in a given calculus). For instance, Pdata and Pf un are two views of the 
same program (this is justified later in the paper). 



3.2 A Solution to the Modular Maintenance Problem 

We illustrate the use of views to solve the problem of modularity in evolutions by building an automated 
transformation of Pdata into Pf„ n and its reverse transformation. 

With such a tool, the programmer can choose the view in which the evolution he has to implement is 
modular. Fig. |5(bj] illustrates the scenario given in section |2~31 with this approach. For instance, when the 
programmer wants to add a new constructor (evolution 1), the program is presented in the data-centered 
view; when the programmer wants to add a new function (evolution 2), the program is presented in the 
operation-centered view. Since none of these evolutions has to be made transversely to the considered axis 
of decomposition, the views of interest always keep a regular architecture. This approach enables to solve 
the problems 1 and 2 described in section |2"31 

This approach also has the following advantages compared to solutions to the expression problem: 

• It does not rely on a particular programming language. As soon as two alternative programming 
structures can be expressed in a language, the corresponding transformation can be defined. 



• The programmer who implements the evolution does not have to learn a new language or possibly 
complex language features. Of course, he has to cope with several views. 

• The programmer does not have to learn a new type system. In particular, if the programming language 
is strongly typed, the different views are also strongly typed and the types they introduce are closely 
related. In this case, typing issues boil down to verify once for all that the program transformations 
do not break typing. 

• The approach is not limited to the data-centered view versus the function-centered view. It is not 
even limited to two views. 

Of course, this approach is not free from disadvantages: 

• The programmer who implements the evolution has to cope with several views. 

• The transformation has to be implemented, which requires some work from a "transformation de- 
signer" and a supporting tool. 

3.3 Refactoring tools to navigate between views 

Developing a program transformation from scratch is not easy. Refactoring tools provide a simple, high- 
level way to transform programs and are available for several kinds of languages. For this reason, we have 
chosen to explore the use of a refactoring tool to build our example of transformation. 

"Refactoring is the process of changing a software system in such a way that it does not alter the external 
behavior of the code yet improves its internal structure " |13j 

Given our definition of programs and views, a code refactoring changes the views of the considered 
program (a refactoring tool enables to pass from one view to another) . Griswold [TJ] shows that refactoring 
tools can be used to change a function-centered architecture into a data-centered architecture. In particular, 
he exemplifies his technique with the program Parnas [22| had employed to illustrate different architectures 
for a same program, each with different advantages and disadvantages. Griswold uses refactoring tools to 
improve the structure of code. We adopt a more dynamical point of view, where an improvement is not 
absolute, but driven by a temporary need: once the driving evolution is implemented, we may need to 
revert to the initial architecture. 

Some refactoring tools are provided with most popular IDEs, for several mainstream languages (Java 
in Eclipse [3J and NetBeans [T], C++, C#, VB in Visual Studio [5]). Refactoring tools have also found 
an interest in the academic community, and some tools which are based on sound foundations have been 
proposed, for instance for Haskell and Erlang [5D], C [35], Smalltalk [23] or Lisp [TSJ. Finally, some 
refactoring tools have been specifically designed to support views in an object-oriented context [7] [23] (see 
section l6.3p . 

It is important to note that some refactoring tools are not sound. In particular, with the Eclipse 
refactoring tool for Java, after refactoring operations have been applied, the user has to fix broken code 
himself [3J [2] ■ For this reason, we focus in this paper on one of the refactorers which provides operations 
whose principles have been proved correct: the Haskell Refactorer (HaRe) [HEHHS]- The formalism used 
in [19j is a A-calculus with let-rec with a mixed call-by-name/call- by- need strategy. A relation of equivalence 
based on the reduction rules of that calculus expresses the behavior preservation which is used to prove the 
correctness of the operations. 

Before applying a refactoring operation, the Haskell Refactorer checks that the conditions to ensure its 
correctness are verified. For instance, it checks that a renaming does not introduce a name clash. When 
these conditions are not verified, the refactorer does not apply the changes and explains why. 

4 Implementation of an Architecture Transformer with a Refac- 
torer 

In this section, we show how Pf un can be transformed into Pdata by using the Haskell Refactorer, and the 
other way around. We also show how the chain of refactoring operations can be automated. 

4.1 Decomposing the transformation into refactoring operations 

We describe in this section the steps to transform Pf un into Pdata with the Haskell Refactorer. As already 
said, each of these operations checks that the conditions that make the refactoring correct are verified. 



In the following, we consider only the eval function. The chain of operations is the same on the 
toString function. Here is the code which is considered in Pf un : 



-- from EvalMod 
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eval (Const i) 


= i 










eval (Add (el,e2)) 


= eval 


el 


+ 


eval 


e2 



--from Client 

r2 = print (show (eval el)) 

r4 = print (show (eval e2)) 



We now present the transformation steps. All the fragments of code we show in this section are the 
result of the use of the refactorer (except for the comments introduced by — and some empty lines which 
are skipped). 

1. We introduce new local definitions for the code of each constructor case (Haskell Rcfactorer's Introduce 
New Definition operation). 



eval (Const i) = evalConst 
where 

evalConst = i 
eval (Add (el,e2)) = evalAdd 
where 

evalAdd = (eval el) + (eval e2) 



2. In each of these new definitions, depending on the constructor concerned (Const or Add), we generalize 
cither the arguments of the constructor, or the recursive calls of eval on these arguments (Generalise 
def). 



eval (Const i) = evalConst i 
where 

evalConst x = x 
eval (Add (el,e2)) = evalAdd (eval el) (eval e2) 
where 

evalAdd x y = (x) + (y) 



3. We lift the new local definitions to make them global (Lift Definition to Top Level). 



eval (Const i) = evalConst i 

eval (Add (el,e2)) = evalAdd (eval el) (eval e2) 

evalAdd x y = (x) + (y) 

evalConst x = x 



4. In the definition of eval, we generalize evalConst and evalAdd (Generalise def). 



eval a c (Const i) = c i 

eval a c (Add (el,e2)) = a (((eval a) c) el) (((eval a) c) e2) 



By applying that operation, all the existing references to eval, in particular in the module Client, 
are transformed to take the new parameters into account. In the body of eval, references to eval 
arc replaced by ((eval f_Add) f_Const). In the module Client, references to eval are replaced by 
eval eval_gen_l eval_gen where eval_gen is defined by evalConst in EvalMod and eval_gen_l is 
defined by evalAdd. 



-- from EvalMod module 
eval_gen_l = evalAdd 

eval_gen = evalConst 



-- 


from Client module 






\ 


r2 


= print (show (eval 


eval_gen_ 1 


eval_gen 


el)) 


r4 


= print (show (eval 


eval_gen_ 1 


eval_gen 


82)) 



5. We rename eval into f oldl (Rename) 



-- from EvalMod module 

foldl a c (Const i) = c i 

foldl a c (Add (el,e2)) = a (((foldl a) c) el) (((foldl a) c) e2) 



-- 


from Client module 






• 


r2 


= print (show (foldl 


eval_gen_ 1 


eval_gen 


el)) 


r4 


= print (show (foldl 


eval_gen_ 1 


eval_gen 


e2)) 



6. We introduce a new definition named eval for the expression foldl eval_gen_l eval_gen el in the 
module Client, we lift it at the top level, and abstract it over el. 



r2 = print (show (eval el)) 

eval x = foldl eval_gen_l eval_gen x 

r4 = print (show (foldl eval_gen_l eval_gen e2)) 



7. We fold the definition of eval to make it appear in r4 (Fold Definition). 



r2 = print (show (eval el)) 

eval x = foldl eval_gen_l eval_gen x 

r4 = print (show (eval e2)) 



8. We unfold the occurrences of eval_gen and eval_gen_l (Unfold def) and we remove their definitions 
(Remove def). 



eval x = foldl evalAdd evalConst x 



9. We move the definitions of evalConst and evalAdd from EvalMod to ConstMod and AddMod and 
rename them into eval. 



r2 = print (show (Client. eval el)) 

eval x = foldl AddMod . eval ConstMod . eval x 

r4 = print (show (Client. eval e2)) 



10. We move the definition of foldl into the Expr module. The module EvalMod is now empty. 

11. We remove useless imports of module EvalMod in the module Client (Clean imports). 

In practice, after this sequence of refactorings, foldl and the f old2 we get from the transformation of 
toString are a-equivalcnt. One of them may be deleted to find the exact Pdata described in section \2. II 
(this seems not to be supported by the Haskell Refactorer at the moment). 

The layout is also not exactly the same as expected (e.g., there are additional pairs of parenthesis). 

10 



Soundness. If we use behavior preserving rcfactoring operations, then the chain of refactoring operations 
is also behavior preserving (and Pf un is equivalent to Pdata)- Some Haskell Rcfactorer's opcrations's princi- 
ples have been shown to be correct |26l 119] . However, there are some bugs left in the implementation, and 
not all the available operations have been proved correct, including some of the ones we are usingj 

Reverse transformation. A simple approach to build the reverse transformation would be to use the 
inverse of each operation used in the Pf un — > Pdata transformation in the reverse order (since (/ o g)~ x = 
g^ 1 o / _1 ). However, the Haskell Refactorer does not provide an inverse for each operation, so our reverse 
transformation cannot be automatically derived from the first transformation. 

We do not detail here the reverse transformation (the script is given in Figs |8] and [9] ) . The key steps 
are to unfold the instances of ConstMod.eval, ConstMod.toString, AddMod.eval, AddMod.toString and 
to transform eval and toString, which are defined by calls to f old_l and f old_2, into plain recursive 
function definitions. This particular step is done by using the Generative Fold operation of the Haskell 
Refactorer (folding in [TU], see [5]). Note that to use the generative fold, a preliminary step has to be done 
by hand: a function definition must be duplicated into a comment. We have introduced in the Haskell 
Refactorer a feature to support this duplication into comments in order to make the whole chain supported 
by the tool and to be able to automate it. 

We also have had to add some features to the refactorer to simplify the code we get after unfolding 
some functions defined by equations with patterns in order to reach the code of Pdata (see appendix [B] for 
the list of operations we have implemented into HaRe). 

4.2 Automation of the process. 

An engineering effort has been necessary to automate the transformation since the API of the Haskell 
Refactorer does not match our needs. In particular, HaRe is designed to be used interactively with text 
editors as Emacs and the parameters of the operations are cursor positions (line and column numbers) 
in source files. For this reason we have developed functions to locate sub-expressions of interest in files 
before calling HaRe operations with the computed parameters. This allows us to provide new interfaces 
for HaRe operations (at least for those we needed) that do not rely on the particular layout in the source 
files (see appendix IA1 for the list of interfaces to HaRe operations we have implemented). Like original 
HaRe operations, our interfaces to HaRe operations are available as Emacs-Lisp functions in addition to 
interactive menu entries. This allows to invoke them in Emacs-Lisp programs. 

Our transformations can thus be expressed by Emacs-Lisp programs. Since these programs are re- 
duced to sequences of operations with side-effects, we call them scripts. Fig. [7] shows the script of the 
transformation Pf un — > Pdata (we assume the definitions of Fig. [6] are evaluated first). 



( def var 


f 1 


" eval " 




N 


( def var 


f 2 


11 toString " 




( def var 


cl 


" Const " 






( def var 


c2 


"Add" 






( def var 


f Imod 


"EvalMod " 




( def var 


f 2mod 


"ToStringMod" ) 


( def var 


f lcl 


C concat 


f 1 


cl) ) 


( def var 


f lc2 


C concat 


f 1 


c2) ) 


( def var 


f 2cl 


C concat 


f 2 


cl) ) 


( def var 


f 2c2 


C concat 


f 2 


c2) ) 


( def var 


clmod 


C concat 


cl 


"Mod")) 


( def var 


c2mod 


C concat 


c2 


"Mod")) 


( def var 


f lreducer 


"f oldl" 






( def var 


f 2reducer 


"f old2" 






( def var 


dummy c 1 


ii c M 






( def var 


dummyc2 


ii a n 






( def var 


clientmod 


"Client 









Figure 6: Pf un —* Pdata script preliminary definitions 



2 This problem is different from the problem in Eclipse for which the answer is : "If the refactoring causes problems in 
other methods, these are ignored and you must fix them yourself after the refactoring. " [3] and "Note that some modifications 
you make to the method, such as adding a parameter or changing a return type, may cause the refactored code to contain 
compiler errors because Eclipse doesn't know what to enter for those new parameters." [2], 
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;; 1 - introduce new definitions 

(haskell-ref ac-exhibitFunction fl cl flcl flmod) 

(haskell-refac-exhibitFunction fl c2 flc2 flmod) 

(haskell-ref ac-exhibitFunction f2 cl f2cl f2mod) 

(haskell-ref ac-exhibitFunction f2 c2 f2c2 f2mod) 



abstract some arguments in these definitions 



(haskell-refac- 
(haskell-refac- 
(haskell-refac- 
(haskell-refac- 
(haskell-refac- 
(haskell-refac- 



jeneralise fl cl flcl flmod 

generalise f2 cl f2cl f2mod 

generalise f2 c2 f2c2 f2mod 

generalise f2 c2 f2c2 f2mod 

generalise fl c2 flc2 flmod 

generalise fl c2 flc2 flmod 



11 0" 


II x II 


" Curried " 


' OtherType 1 


) 


11 0" 


II x II 


" Curried " 


' OtherType' 


) 


„ )_„ 


"y" 


" UnCurried 


1 " RecType ' 


) 


11 0" 


ii x ii 


" UnCurried 


1 " RecType ' 


) 


„ j^l 


"y" 


" UnCurried 


1 " RecType ' 


) 


11 0" 


ii x ii 


" UnCurried 


1 " RecType ' 


) 



;; 3 - lift the new functions to the top-level 
(haskell-refac-makeGlobalOfLocalln fl flcl flmod) 
(haskell-refac-makeGlobalOfLocalln fl flc2 flmod) 
(haskell-ref ac-makeGlobalDf Localln f2 f2cl f2mod) 
(haskell-ref ac-makeGlobalDf Localln f2 f2c2 f2mod) 

;; 4- ~ abstract the functions of interest from the introduced functions 
(haskell-ref ac-generaliseldent fl flmod flcl dummy cl ) 
(haskell-refac-generaliseldent fl flmod flc2 dummy c 2 ) 
(haskell-refac-generaliseldent f2 f2mod f2cl dummy cl ) 
(haskell-refac-generaliseldent f2 f2mod f2c2 dummy c 2 ) 

;; 5 - rename the functions of interest (they have become traversal functions) 
(haskell-refac-renameToplevel fl flmod flreducer) 
(haskell-refac-renameToplevel f2 f2mod f2reducer) 

;; 6 - reconstruct the functions of interest as calls to the traversal functions 
; ; with appropriate arguments 

(haskell-refac-newDefFunApp flreducer "3" fl clientmod) 
(haskell-refac-newDefFunApp f2reducer "3" f2 clientmod) 
(haskell-refac-makeGlobalOfLocal fl clientmod) 
(haskell-refac-makeGlobalOfLocal f2 clientmod) 
(haskell-refac-generaliseldent fl clientmod "el" "x") 
(haskell-refac-generaliseldent f2 clientmod "el" "x") 

;; 7 - propagate the new definitions 

(haskell-refac-foldToplevelDefinition fl clientmod) 
(haskell-refac-foldToplevelDefinition f2 clientmod) 

;; 8 - unf old dummy definitions and remove them 

(haskell-ref ac-unfoldlnstanceln (concat fl "_gen") fl clientmod) 

(haskell-ref ac-unfoldlnstanceln (concat fl "_gen_l") fl clientmod) 

(haskell-ref ac-unfoldlnstanceln (concat f2 "_gen") f2 clientmod) 

(haskell-ref ac-unfoldlnstanceln (concat f2 "_gen_l") f2 clientmod) 



(haskell-ref ac-removeDefCmd (concat fl 

(haskell-ref ac-removeDefCmd (concat fl 

(haskell-ref ac-removeDefCmd (concat f2 

(haskell-refac-removeDefCmd (concat f2 



_gen " ) f lmod) 
_gen_l") flmod) 
_gen " ) f 2mod) 
_gen_l " ) f 2mod) 



;; 9 - move business functions to the appropriate modul es 
(haskell-refac-moveDefBetweenModules flcl flmod clmod) 
(haskell-refac-moveDefBetweenModules flc2 flmod c2mod) 
(haskell-refac-moveDefBetweenModules f2cl f2mod clmod) 
(haskell-refac-moveDefBetweenModules f2c2 f2mod c2mod) 

;; rename the business functions to make them share the same name 
(haskell-refac-renameToplevel flcl clmod fl) 
(haskell-refac-renameToplevel flc2 c2mod fl) 
(haskell-refac-renameToplevel f2cl clmod f2) 
(haskell-refac-renameToplevel f2c2 c2mod f2) 

;; 10 - move the functions into the relevant modul es 
(haskell-refac-moveDefBetweenModules flreducer flmod "Expr") 
(haskell-refac-moveDefBetweenModules f2reducer f2mod "Expr") 

;; 11 - clean imports 
(haskell-refac-cleanlmportsCmd clientmod) 



Figure 7: Pf un — > Pdata transformation script 
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; ; reverse 10 - 

(haskell-refac-moveDefBetweenModules flreducer "Expr" flmod) 

(haskell-refac-moveDefBetweenModules f2reducer "Expr" f2mod) 

;; reverse 9 - use specific names for business functions 
(haskell-refac-renameToplevel fl clmod flcl) 
(haskell-refac-renameToplevel f 1 c2mod flc2) 
(haskell-refac-renameToplevel f2 clmod f2cl) 
(haskell-refac-renameToplevel f2 c2mod f2c2) 

;; reverse 9 - move business functions to the original modules 
(haskell-refac-moveDefBetweenModules flcl clmod flmod) 
(haskell-refac-moveDefBetweenModules flc2 c2mod flmod) 
(haskell-refac-moveDefBetweenModules f2cl clmod f2mod) 
(haskell-refac-moveDefBetweenModules f2c2 c2mod f2mod) 

; ; move fl f2 to flmod f2 mod 

(haskell-refac-moveDefBetweenModules fl clientmod flmod) 
(haskell-refac-moveDefBetweenModules f2 clientmod f2mod) 

(haskell-refac-cleanlmportsCmd clientmod) 

;; reverse J^/ '5/6/7 - transform a call to fold into a recursive function 

;; prepare the generative fold operations : 

; ; the equations for functions of interest are saved into comments 

(haskell-refac-dupli cat e Into Comment fl flmod) 

(haskell-refac-dupl icat elnt o Comment f2 f2mod) 

; ; unfo Id the use of the traversal function 
; ; in the definition of functions of interest 
(haskell-refac-unfoldlnstanceln flreducer fl flmod) 
(haskell-refac-unfoldlnstanceln f2reducer f2 f2mod) 

;; unfolding has produced case expressions that have 
; ; to be simplified 

(haskell-refac-simplifyCasePattern fl flmod) 
(haskell-refac-unfoldlnstanceln dummy c 2 fl flmod) 
(haskell-refac-unfoldlnstanceln dummy c 2 fl flmod) 
(haskell-refac-unfoldlnstanceln dummy c 2 fl flmod) 
(haskell-refac-removeLocalDef dummy c 2 fl flmod) 

(haskell-refac-simplifyCasePattern fl flmod) 
(haskell-refac-unfoldlnstanceln dummy cl fl flmod) 
(haskell-refac-unfoldlnstanceln dummy cl fl flmod) 
(haskell-refac-unfoldlnstanceln dummy cl fl flmod) 
(haskell-refac-removeLocalDef dummy cl fl flmod) 

(haskell-refac-simplifyCasePattern f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy c 2 f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy c 2 f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy c 2 f2 f2mod) 
(haskell-refac-removeLocalDef dummy c 2 f2 f2mod) 

(haskell-refac-simplifyCasePattern f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy cl f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy cl f2 f2mod) 
(haskell-refac-unfoldlnstanceln dummy cl f2 f2mod) 
(haskell-refac-removeLocalDef dummy cl f2 f2mod) 

;; the case expressions introduced by the unfolding 
; ; have to be transformed into equations 
(haskell-refac-caseToEq fl flmod) 
(haskell-refac-caseToEq f2 f2mod) 

fold the use of the traversal function in the body of the 
functions of interest in order to get a recursive definition 
(without a call to the traversal function) 

(haskell-refac-generativeFold flreducer "3" flmod) 

(haskell-refac-generativeFold flreducer "3" flmod) 

(haskell-refac-generativeFold f2reducer "3" f2mod) 

(haskell-refac-generativeFold f2reducer "3" f2mod) 

; ; comment s introduced for the generative fold can be deleted 
(haskell-refac-rmCommentBefore fl flmod) 
(haskell-refac-rmCommentBefore f2 f2mod) 

;; the traversal functions can be deleted 

(haskell-refac-removeDefCmd flreducer flmod) 

(haskell-refac-removeDefCmd f2reducer f2mod) 

;; end of the trans format ion of the call to fold into a recursive function. 



Figure 8: Pdata ~^ Pfun transformation script (first part) 
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Figure 9: Pdata —> Pfun transformation script (end) 

5 Usage and Future Work 

This section discusses the possibility of using views with the tool we demonstrated here and proposes future 
works to improve this use. 

Development of the transformation. The first problem with our setting is that the transformation 
has to be implemented. We could ease this task by several means: 

• Compute automatically the transformation based on the hints of the designer, as done in [7] and [23] 
or provide a more high level transformation specific language. 

• Provide a list of examples to be used as transformation patterns. 

• Once a transformation is defined, generate automatically the inverse transformation. 

• Record the sequence of commands used in an interactive rcfactorer (as Eclipse does [5]). 

Maintenance of the transformation. As the program evolves, the transformation may need to evolve 
too. We could study how an evolution impacts a transformation. Some simple examples seem to be directly 
tractable: for instance, if the evolution to be implemented is the renaming of a function, we can imagine 
that the rcfactoring tool that propagates the renaming could also propagate it into the transformation 
script. 

Duration. The transformation of our example takes about 15 seconds (on a 2.8 GHz Intel Pentium R 
processor) and 7 seconds for the reverse transformation. This is longer than the compile time of the program 
(less than 1 sec). We can suppose that the transformations can be integrated into the build process that 
takes place once a new version of the code is released, so that when a programmer has to implement an 
evolution, all the designed views are available. Of course, this supposes all the views have been designed 
together with the initial program. 

Availability of a tool for a given language. We have chosen to use an existing rcfactoring tool instead 
or rebuilding one. We have produced 615 LOC to implement missing rcfactoring operations and 1160 LOC 
for the new interface. This has to be compared to the size of a refactoring tool (11 KLOC for Arcum |24|V 
So our approach depends on the tools available for the language of interest. 

Failures From an operational point of view, as each operation of the chain requires some pre-conditions 
to be satisfied, it may occur that the user is informed that the transformation cannot be achieved only 
after some operations have been applied. In order to inform the user as soon as possible (statically instead 
of dynamically) that the transformation cannot be applied, we could compute the pre-condition of the 
transformation, for instance by following the work of Kniesel and Koch [17) . This would imply to provide 
a formal description of the pre-conditions and effects (post-conditions or Kniesel and Koch's backward- 
descriptions) of all the operations used. 

6 Conclusion 

6.1 Contributions. 

The contributions of this report are the following: 
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• We give an example of use of multiple views in a functional programming language. That example 
comes from the expression problem. 

• We implement that transformation with an existing refactorer, the Haskell Rcfactorer, and we auto- 
mate it. To be able to do this, we extend the interface of the rcfactorer and add a few operations in 

it. 

6.2 Comparison to view tools 

Compared to some other multiple views implementations (in particular [7], |24] ) and to the implementation 
of |15j . our approach has the following pros and cons: 

• © We rely on a previously existing refactorer. We had to implement few lines of code to adapt 
it to support views. The engineering effort is very small compared to building a dedicated tool. 
Moreover, the basic operations are already proved correct (yet not all of them, and not the concrete 
implementation) . 

• Q The expression of the transformation is rather low level. It is imperative (as in |15j ) while in [7] 
and [23] it is declarative. Moreover, it is not automatically invertible. 

• 7^ We focus on dealing with fragments of business code while [7] focuses on classes and method 
interactions and |14j focuses on data-structure encapsulation (at least in the example from Parnas). 

6.3 Related Work 

Offering to the programmer (or designer or specifier) an appropriate view is not a new idea. Here is a 
review of some relevant related work. 

Before Wadler introduced the expression problem [28] , he had already proposed the notion of views [27] . 
His view feature makes it possible to use pattern matching with different representations of a data structure. 
At compile time different views of a data structure are defined and their relationships are specified by 
rewriting rules. At run-time, a single data structure is maintained and pattern matching on different 
representations are translated to accessor functions that compute a (partial) view from another one. This 
is closely related to our problem, but we do not focus on data structures but on code structures and we 
extend and maintain programs before run-time. 

Griswold [141 115] shows that elementary refactoring operations can be chained to provide architecture 
transformations. However, as already said in section [3.31 while Griswold's goal is to improve the structure 
of code, our goal is to dynamically adopt a structure which is convenient for a given task. 

We share with Black and Jones [7] the same motivation and the idea that multiple views solves the 
tyranny of dominant decomposition problem. However, the techniques are rather different. In their im- 
plementation, the programmer describes properties of the fragments of code which are used to compute 
the views. In Shonle et al. [23], it is the transformation which is described. It is described declaratively 
by rewriting rules. Both works handle mainly object oriented language concepts (classes, methods, field 
accesses) . 

Functional programs are prone to be transformed. Numerous program transformations have been pro- 
posed. Some comes in pairs, or are invertible. For instance, Danvy have studied relationship between the 
continuation passing style and the direct style [TT]. In general a program transformation is not invertible. 
Forstcr ct al. [T2] have proposed a domain specific language to define invertible transformations. Once 
a transformation is specified, the inverse transformation is automatically derived. This enables them, for 
instance, to share data between several applications that require different representations. Note that, a 
view can be partial and the original representation can be required in order to transform a modified view 
back to its original form by injecting the updated data. This work has been extended in order to deal with 
classes of equivalent representations (e.g., two lists of associations (key, value) can be equivalent even if the 
order of the pairs are different) [5]- 

Views have also been introduced at the specification level. For instance, Jackson [16] shows how to 
compose Z specifications on different views of the same state. At the specification level, the composition is 
not computational (it does not require transformation) but declarative: invariants relate the different views 
of the state. 

Literate programming 18| proposes to invert the role of code and comments (comments becomes the 
main view of a program and is commented by a few pieces of code) . More importantly, literate programming 
enables to decompose and reorder pieces of programs. This way, the literate view for human has to be 
transformed into the code view for the compiler. However, the transformation is single way. This does not 
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help for the maintenance or the evolution problem (since the code is not transformed but only reordered) 
but this proves its is important to present alternative views for the programmer. 

Web Sites 



[1] Rcfactoring - NctBcans Wiki. http : //wiki . netbeans . org/Ref actoring 



[2] P. Deva. Explore refactoring functions in Eclipse JDT. http : //www . ibm . com/developerworks/opensource/library/ 
Nov. 2009. 



[3] D. Gallardo. Rcfactoring for everyone, http://www.ibm.com/developerworks/library/os-ecref/ 
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A Interfaces added to Refactoring Operations 

Introduce new def. 

• haskell-ref ac-exhibitFunction f c n m 

In the equation concerning the constructor c in the definition of f in the module m, create a new local 
definition for the right hand side of the equation as n . 

• haskell-ref ac-newDef FunApp f n f ' m 

Find an application of the identifier f to n arguments in the module m and create a new local definition 
for that application as f ' . 

Generalise def. 

• haskell-ref ac-generalise f c f ' m n x curry "OtherType" 

In the module m, in the equation concerning the constructor c of the definition of f , let v be the n th 
argument of the constructor c in the pattern of the equation, generalise v in the local definition of f ' 
and name x the new argument. 

The flag curry indicates whether the arguments of the constructor are curried or not to count the 
arguments. 

• haskell-ref ac-generalise f c f ' m n x curry "RecType" 

In the module m, in the equation concerning the constructor c of the definition of f, let v be the n th 
argument of the constructor c in the pattern of the equation, generalise an application of f to v in 
the local definition of f ' and name x the new argument. 

• haskell-ref ac-generaliseldent f m v x 

In the definition of f in the module m, generalise the variable v and name the new parameter x. 
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Lift def to top level. 

• haskell-ref ac-makeGlobalOf Localln f d m 

Lift the definition of d at the top-level, d is declared inside the definition of f in the module m, 

Rename. 

• haskell-ref ac-renameTopLevel f m f ' 

Rename t declared at the top-level in the module m into f ' . 

Move def to another module. 

• haskell-ref ac-moveDef BetweenModules f m m' 

Move the top-level definition of f from module m to module m ' . 

Unfold def. /Fold def. 

• haskell-ref ac-unf oldlnstanceln d f m 

Replace an instance of the identifier d by the boy of its definition, in the body of f in module m. If 
possible, a beta-reduction is applied (see the corresponding HaRc operation). 

• haskell-ref ac-f oldToplevelDef inition f m 

Fold the definition of function f of module m (see the corresponding HaRe operation) . 

Generative Fold 

• haskell-ref ac-generativeFold f "i" m 

Select an application of the identifier f to i arguments in m and apply HaRe Generative Fold operation 
on it (a comment must be present before the affected declaration, see the HaRe operation). 

Remove def. 

• haskell-ref ac-removeDef Cmd f m 

Remove the definition of f in the module m. f must not be used elsewhere. 

• haskell-ref ac-removeLocalDef d f m 

Remove the definition of d which is local to f in the module m. f must not be used elsewhere. 

Clean imports, Remove from export. 

• haskell-ref ac-cleanlmportsCmd m 

Call the Clean imports operation on the module m (remove the useless imports). 

• haskell-ref ac-rmFromExports f m 

Remove f from the explicit exports of the module m. f must not be used in an other module. 



B Added Refactoring Operations 



Simplify a case pattern matching. This operation transforms the first code below into the second code 
below. 



case ( el , e2 


, e3) 


of 


■ 


(y. 


pll, 


pl2) 


-> bl 


(y, 


p21, 


p22) 


-> b2 



let y = el 

in case (e2, e3) of 

(pll , pl2) -> bl 
(p21 , p22) -> b2 
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The patterns and the matched expression have to be tuples. 

The refactoring applies when there is a same identifier at the same position in all the pattern tuples. 

Input : select the whole case expression. 

haskell-ref ac-simplif yCasePattern f m 

Apply the above operation on a case expression in the definition of f in the module m. 

Transform a case pattern matching into equations. Transforms the first code below into the second 
code below. 



x = case (x) of 

pi -> el 
p2 -> e2 



f pi = el 
f p2 = e2 



The pattern in the initial case has to be reduced to a variable which occurs as a parameter of the 
function. 

A second version of this function is available for pattern matching on pairs: 



f x y = case (x,y) of 

(pll,pl2) -> el 
(p21,p22) -> e2 



f pll pl2 = el 
f p21 p22 = e2 



haskell-ref ac-caseToEq f m 
haskell-ref ac-caseToEq2 f m 

Select the case expression which is at the top-level of the body of the declaration of f in the module 
m and transform it into a set of equations. 

Copy a declaration into a comment. Makes a copy of a declaration into a comment placed just above 
the declaration (to be used before applying Generative Fold). 

haskell-ref ac-duplicatelntoComment f m Copy of the declaration of f of the module m. 

Remove a comment. Deletes a comment. 

haskell-ref ac-rmCommentBef ore f m Delete the comment occurring before the declaration of f at 
the top-level of the module m. 
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